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Description 

AUTO-LINKING OF FUNCTION LOGIC 
STATE WITH TESTCASE REGRESSION LIST 

Background of Invention 
[0001] l.Technical Field 

[0002] The present invention relates in general to the field of 
logic design testing, and in particular to the accurately 
defined logic areas in the logic design. Still more particu- 
larly, the present invention relates to a method and sys- 
tem for associating specific logic areas with specific tests, 
such that a change in the specific logic area or a change in 
the test will require re-testing only affected logic areas. 

[0003] 2. Description of the Related Art 

[0004] Building computer logic takes many steps before the 

computer logic is physically manufactured. The logic de- 
signer typically uses synthesis tools, known as Hardware 
Descriptor Languages (HDLs), to describe, design and 
document electronic circuits, as well as simulating faults, 



in software simulations of hardware. Examples of HDLs 
are Verilog® and VHDL 

(Very-high-speed-integrated-circuit Hardware Descriptor 
Language) for Very Large Scale Integrated Circuits 
(VLSICs); and Register Transfer Language (RTL) to describe 
registers in computer logic and the way that data is trans- 
ferred between such registers. By including a description 
of interfaces for logic and the logic's behavior, HDLs sim- 
ulate physical hardware to such an extent that a virtual 
machine can be constructed in software alone. Such vir- 
tual machines are made up of multiple Finite State Ma- 
chines (FSMs), also referred to as function areas or logic 
areas. Examples of FSMs are error correction logic, arbi- 
tration units, flow-control management units for deter- 
mining if packets can be sent, etc. 
[0005] After being constructed in software, the virtual machine is 
tested using an Architecture Verification Program (AVP), 
which is a test-case format that specifies an initial input 
and expected output of the virtual machine. The AVP is 
made up of multiple testcases, each of which affect one or 
more FSMs. Although an AVP may be useful in determin- 
ing if an entire virtual machine is working, erroneous out- 
puts from the virtual machine alone do not identify which 



FSM or FSMs are responsible for the failure. While docu- 
mentation comments in the AVP may attempt to identify 
affected FSMs and thus the source of the failure, such 
predictions are rarely complete due to unexpected conse- 
quences of test software on FSM architecture, as well as 
unexpected anomalies in the FSM architecture itself. Thus, 
upon a test failure, the tester of the virtual machine must 
modify the FSMs predicted by the AVP programmer to be 
affected by the AVP, and then the entire AVP is re-run. 
Such a process is very time consuming, as a full AVP may 
take days to run, making such a process inefficient. 
[0006] what is needed, therefore, is a method of accurately iden- 
tifying which FSMs are affected by a testcase. This would 
allow an engineer to adjust/correct only FSMs affected by 
a failed testcase. Such a method also would allow the en- 
gineer to make changes to the virtual machine, followed 
by re-testing of only affected FSMs, thus reducing the 
time to re-test the newly modified virtual machine. 
Summary of Invention 

[0007] The present invention is directed to a method and system 
for identifying logic function areas, which make up a vir- 
tual machine, that are affected by specific testcases. A 
Hardware Descriptor Language (HDL) is used to create a 



software model of the virtual machine. A simulator com- 
piles and analyzes the HDL model, and creates a matrix 
scoreboard identifying logic function areas in the virtual 
machine. A complete list of testcases is run on the virtual 
machine while a monitor correlates each testcase with af- 
fected logic function areas to fill in the matrix scoreboard. 
When a subsequent test failure occurs, either because of a 
modification to a logic function area, or the execution of a 
new test, all logic function areas that are affected, either 
directly or indirectly, are identified. This accurate identifi- 
cation allows a tester to correct only such affected logic 
areas, thus resulting in a savings in test time and re- 
sources. 

[0008] The above, as well as additional objectives, features, and 
advantages of the present invention will become apparent 
in the following detailed written description. 
Brief Description of Drawings 

[0009] The novel features believed characteristic of the invention 
are set forth in the appended claims. The invention itself, 
however, as well as a preferred mode of use, further ob- 
jects and advantages thereof, will best be understood by 
reference to the following detailed description of an illus- 
trative embodiment when read in conjunction with the ac- 



companying drawings, where: 

[0010] Figure 1 depicts a logical device under test (DUT), includ- 
ing multiple logic areas; 

[001 1] Figure 2 is a block diagram of software used by the 
present invention, including a scoreboard generating 
monitor; 

[0012] Figures 3a and 3b illustrate the scoreboard, generated by 
the monitor, describing which logic areas in the DUT are 
affected by specific testcases; 

[0013] Figure 4 depicts an addition of a new logic area to the 
DUT; 

[0014] Figure 5 illustrates which test cases fail after altering a 
logic area; 

[0015] Figure 6 is a flow-chart of steps taken in practice of a 
preferred embodiment of the present invention; and 

[0016] Figure 7 depicts a preferred data processing system used 
to control and manage the present invention. 
Detailed Description 

[0017] with reference now to the figures and in particular to Fig- 
ure 1, there is depicted a block diagram of a Device Under 
Test (DUT) 100. DUT 100 is a software model, built with a 
Hardware Descriptor Language (HDL) synthesis tool, hav- 
ing multiple logic areas 1-8, also known as "logic states." 



As illustrated, logic areas 1 and 2 have an overlap 102, 
which is a logical overlap of function or interrelationship, 
and/or a physical overlap according to the ultimate physi- 
cal proximity between two logic areas on a physical chip 
being modeled by a Hardware Descriptor Language (HDL). 
If overlap 102 is a logical overlap, then a process per- 
formed in logic area 1 directly affects logic are 2, such as 
providing a branch node, calculation result, decision step, 
etc. While logic areas 3-6 are not directly affected by logic 
area 1, logic areas 3-6 are indirectly affected by logic area 
1 since logic areas 3-6 are directly affected by logic area 
2. 

[0018] Logic area 7 is not affected, either directly or indirectly, by 
logic area 1, even though logic area 7 does perform some 
type of logical function that may impact on other logic ar- 
eas (not shown) in DUT 100. Logic area 8, which is part of 
a pass-through logic 104, is also not affected by logic 
area 1, since pass-through logic 104, which may be a 
scan chain or other type of pass-through logic, does not 
directly interact with any of the other logic areas in DUT 
100. 

[0019] with reference now to Figure 2, there is depicted a block 
diagram of software used by the present invention. A test 



list 202 includes an entire regression list of tests for a de- 
vice under test (DUT) 208, which comprises multiple logic 
areas. A simulator 204, interfaces between DUT 208 and a 
test bench 206, which contains a test, from test list 202, 
that is currently being executed. Simulator 204 simulates 
events that incorporate features of the currently executing 
test. These events are updated during the test execution 
by simulator 204 with test bench 206. These simulated 
events are exchanged back and forth with DUT 208 to 
further update the simulation. Test bench 206 preferably 
directly monitors logic areas. That is, in a physical logic 
area, a physical probe would directly monitor whether the 
physical logic area was being "hit" by a software opera- 
tion. In a software model such as DUT 100, the virtual 
logic areas are monitored by test bench 206, which in- 
cludes software to monitor is a virtual logic area has been 
"hit." This monitoring is preferably performed by monitor- 
ing flags, condition states, or other registers/memory that 
indicate that a particular logic area is receiving data input 
and, usually, outputting data processing results. 
[° 02 °] Simulator 204 also includes a compiler 214, which is used 
prior to execution of testing to define logic areas in DUT 
208. These logic areas are used to construct a testcase 



scoreboard 212, about which more is described below. 
[0021] a monitor 210 correlates logic state areas in DUT 208 

with specific testcases from test list 202. This correlation 
is used to both create as well as fill in a testcase score- 
board 212. That is, on a first pass, monitor 210 begins 
the creation of an empty matrix scoreboard 212 as shown 
in Figure 3a, in which logic areas are defined according to 
an analysis of the compiled HDL defining DUT 208. On a 
second pass, monitor 210 completes testcase scoreboard 
212, as shown in greater detail in Figure 3b, by checking 
off each logic area that is affected by each newly added 
testcase. As shown in exemplary Figure 3b, Testcase A af- 
fects logic areas 1, 3 and 5, while Testcase B affects only 
logic areas 3 and 4. The "X" notations in Figure 3b repre- 
sent a correlation performed by monitor 210, which mon- 
itors nodes in DUT 208 for activity caused by a specified 
testcase. 

[0022] After scoreboard 212 has been completed as shown in 

Figure 3b, it can be used to locate likely problem logic ar- 
eas in the future. For example, suppose a new logic area 
402 is added, as shown in Figure 4 within logic area 2. 
Since the scoreboard shown in Figure 3b indicates that 
only Testcases D and E test logic area 2, then only these 



two testcases are run. If Testcases D and E fail, as shown, 
then there are two most probable reasons. The first is that 
new logic area 402 has had a direct adverse effect on 
logic area 2. The second is that new logic area 402 has 
had an indirect adverse effect on logic area 1 or logic area 
5, since these two logic areas are also affected by Test- 
cases D and E. Through the use of the scoreboard shown 
in Figure 5a, a logical decision can be made as to deter- 
mine how to pinpoint where the logic fault lies. 
[0023] a first method to pinpoint the location of the fault is to 

count how many logic areas are involved in the failed test- 
cases. For example, the two failed Testcases D and E 
shown in Figure 5a used logic area 2 twice, but logic areas 
1 and 5 only once. Thus, it can be predicted that logic ar- 
eas 1 and 5 are less likely to be the problem area than 
logic area 2. While such a conclusion is fairly obvious in 
the example shown, in which logic are 2 is the area that 
was altered, this "counting" technique becomes much 
more powerful when there are many more testcases and 
logic areas. In such cases, the logic area having the high- 
est occurrence in failed testcases is often a logic area that 
was NOT altered. In the example shown then, even if logic 
area 2 had not been altered, the appearance of logic area 



2 in both failed Testcases D and E indicates that logic area 
2 is likely the area posing the problem. 

[0024] Alternatively, testcase scoreboard 212 can be used to se- 
lect which testcases are run after Testcases D and E fail, in 
order to more accurately pinpoint where the problem logic 
area is located. Using the illustration of Figure 5a, when 
Testcases D and E fail, a search is made for other test- 
cases using logic areas that are tested by Testcases D and 
E. No other testcases test logic area 2, but Testcase A also 
tests logic areas 1 and 5. Thus, Testcase A is subse- 
quently run, and fails, as shown in Figure 5b. Since Test- 
case A does not use logic area 2, then there is a strong 
presumption that logic area 2 is not the problem after all. 
However, since Testcase A uses logic areas 1 and 5, Test- 
case D uses logic area 1, and Testcase E uses logic area 5, 
then there is a strong likelihood that new logic area 402 
has had an adverse indirect impact on logic areas 1 and 5. 

[0025] with reference now to Figure 6, a preferred embodiment 
of the present invention is described in a flow-chart. 
Starting at block 602, an initial scoreboard is created by 
identifying logic areas in the DUT. A full regression of all 
tests is run on the DUT (block 604), which results in the 
completion of the scoreboard (block 606) identifying each 



logic block affected by each testcase. 

[0026] if a new testcase is added (block 610), it is run. If it passes 
(decision block 614), then no further action is taken. 
However, if the new testcase fails, then other testcases 
that failed are examined and compared (block 622), to 
identify testcases having common logic areas. The pres- 
ence of such common areas is a good indicator of which 
logic area(s) have a problem. 

[0027] |f a new | 0 gj C area j S a dded or an existing logic area is al- 
tered (block 608), then the testcases that use that area of 
logic are run (block 612). If the selected testcases pass 
(decision block 616), then no further steps are taken. 
However, if there are one or more failures in the chosen 
testcases, then the common affected logic areas are 
counted (block 618), and a minimum regression is run us- 
ing testcases that test the affected logic areas, either di- 
rectly or indirectly (block 620), as described above in Fig- 
ure 5b. 

[0028] with reference now to Figure 7, there is depicted a block 
diagram of a preferred embodiment of a data processing 
system 700 used to implement the present invention in 
the creation and logical use of the scoreboard. Data pro- 
cessing system 700 is preferably used to run all software 



described in Figure 2. 

[0029] D a ta processing system 700 includes a processor 702, 

which is connected to a system bus 708. In the exemplary 
embodiment, data processing system 700 includes a 
graphics adapter 704 also connected to system bus 708, 
receiving information for display 706. 

[0030] Also connected to system bus 708 are system memory 
710 and input/output (I/O) bus bridge 712. I/O bus 
bridge 712 couples I/O bus 714 to system bus 708, relay- 
ing and/or transforming data transactions from one bus 
to the other. Peripheral devices such as nonvolatile stor- 
age 716, which may be a hard disk drive, floppy drive, a 
compact disk read-only memory (CD-ROM), a digital 
video disk (DVD) drive, or the like, and input device 718, 
which may include a conventional mouse, a trackball, or 
the like, is connected to I/O bus 714. The software de- 
scribed in Figure 2 is preferably stored in both system 
memory 710 and nonvolatile storage 716. 

[0031] The exemplary embodiment shown in Figure 7 is provided 
solely for the purposes of explaining the invention and 
those skilled in the art will recognize that numerous vari- 
ations are possible, both in form and function. For in- 
stance, data processing system 700 might also include a 



sound card and audio speakers, and numerous other op- 
tional components. All such variations are believed to be 
within the spirit and scope of the present invention. 
[0032] it should be understood that at least some aspects of the 
present invention may alternatively be implemented in a 
program product, preferably performing the functions of 
the present invention in an automatic manner based on 
pre-determined criteria as described, including relative 
logical relationships between and among logic areas. Pro- 
grams defining functions on the present invention can be 
delivered to a data storage system or a computer system 
via a variety of signal-bearing media, which include, with- 
out limitation, non-writable storage media (e.g., CD- 
ROM), writable storage media (e.g., a floppy diskette, hard 
disk drive, read/write CD ROM, optical media), and com- 
munication media, such as computer and telephone net- 
works including Ethernet. It should be understood, there- 
fore in such signal-bearing media when carrying or en- 
coding computer readable instructions that direct method 
functions in the present invention, represent alternative 
embodiments of the present invention. Further, it is un- 
derstood that the present invention may be implemented 
by a system having means in the form of hardware, soft- 



ware, or a combination of software and hardware as de- 
scribed herein or their equivalent. 
[0033] while the invention has been particularly shown and de- 
scribed with reference to a preferred embodiment, it will 
be understood by those skilled in the art that various 
changes in form and detail may be made therein without 
departing from the spirit and scope of the invention. 



